Ethernet is a network standard that can be used for interconnecting computers, printers, servers, and other computer devices within a building or campus. Such devices transmit information over networks using Ethernet packets. An Ethernet packet commonly contains a synchronization preamble, a destination address, a source address, a data field of varying size, and other information. Ethernet packets can be sent over Ethernet cable such as twisted wire, coax cable, or fiber optic cable. In the alternative, Ethernet packets can be sent using radio waves, infrared or other wireless means of communication.
A personal computer is an example of a network device that could communicate over Ethernet. Such communication by a personal computer over Ethernet could occur through hardware commonly-referred to as an Ethernet adapter. An Ethernet adapter is a unit that connects a network device to the Ethernet cable or other transmission medium. Like many other printed circuit boards associated with a personal computer, Ethernet adapters require a software driver to work correctly with the operating system and other computer hardware. For Ethernet adapters, the software driver is commonly referred to as an Ethernet device driver. An Ethernet adapter could also be referred to as an Ethernet controller.
In some operating systems such as AIX, an Ethernet device driver logs all driver error traces into the system trace table that resides in kernel memory. Enabling debug traces results in a loss of performance, therefore debug traces are not enabled by default. To avoid sacrificing performance, user intervention is needed in order to log debug traces. In the AIX operating system, for instance, a developer could type the command “entstat -t” from the Unix command line to turn on debug traces for an Ethernet device driver. To diagnose a problem, the developer can review stored debug trace information and use the information and the kernel dump to help identify the cause of the crash. In many cases however, before a developer can review the stored debug trace information, the developer must reboot a system, turn on debug traces to store information, and attempt to recreate a problem so that the stored information may be reviewed. This method of troubleshooting is time consuming and is often unsuccessful at repeating the symptoms that lead to a crash.
Present systems involving kernel crash dumps are limited due to the limited amount of memory allocated for troubleshooting a specific device such as an Ethernet adapter. Therefore, if an Ethernet device driver or Ethernet adapter has a problem, only a limited amount of information will be available in the debug traces for analysis by a developer. Furthermore, such information is often only available after attempts to recreate a crash after rebooting a system. Often in debugging a problem, a developer must ask his client to enable debug traces, attempt to recreate a problem, and then forward trace tables to the developer. Such a process is time-consuming and often ineffective. Further, if an Ethernet caused a fatal error, the traces in the trace table might not have enough information for debugging the problem.
What is needed is an improved method and apparatus for troubleshooting Ethernet adapters and Ethernet device drivers to allow developers a way of identifying the sources of problems before crashes occur.